AWS｜Well-Architected Framework 信頼性の設計
質問.icon 信頼性(Reliability)とは何か？
システムが一貫して正常に動作し、予期された機能を提供し続ける能力を指す
1.icon可用性：Availability
概要
システムが利用可能な状態にあること。システムが常に稼働しており、ユーザーが必要な時にアクセスできることを保証する。可用性を高めるためには、システムのダウンタイムを最小限に抑える設計や運用が必要
2.icon耐障害性：Fault Tolerance
システムが障害に対してどれだけ耐性を持っているかを示す。ハードウェアやソフトウェアの障害が発生しても、システム全体の運用に大きな影響を与えないような設計(冗長性の確保やフェイルオーバー機能の実装)が必要
3.iconリカバリ：Recovery
システム障害からどれだけ迅速に復旧できるかを指す。リカバリタイムが短いほど、システムの信頼性は高まる
障害発生後の迅速な対応は、データのバックアップや復元手順の確立、テストなどによって達成される
4.iconスケーラビリティ：Scalability
システムが負荷の増加に対応できるかを示す。負荷が増加した際に、システムが適切にスケールアップまたはスケールアウトか等。自動スケーリングや負荷分散を利用することで、システムの信頼性を高めることができる
5.icon監視とアラート：Monitoring and Alerting
システムの状態を継続的に監視し、異常が検出された場合に迅速に対応するためのメカニズム。監視ツールを利用して、システムのパフォーマンスや稼働状況を把握し、問題が発生した際にはアラートを発生させることで、迅速な対応を可能にする
6.icon継続的な改善：Continuous Improvement
信頼性を維持するためには、システムの設計や運用を継続的に改善していくことが重要
定期的なレビューやテスト、障害の分析と改善策の実施を通じて、システムの信頼性を高める取り組みが求められる
memo.icon障害の発生パターン
memo.iconスケールアップ/スケールアウト
質問.icon 信頼性に紐づく指標には何があるのか？
目標復旧時間(RTO：Recovery Time Objective)
システムが障害から復旧するまでに許容される最大時間
障害発生後にどのくらいの時間以内にシステムを再稼働させる必要があるかを表す
目標復旧時点(RPO：Recovery Point Objective)
システム障害などでデータが破損した際に、復旧するバックアップデータの古さの目標
平均故障感覚(MTBF：Mean Time Between Failures)
システムが故障するまでの平均時間
システムがどれだけ長期間安定して稼働するかを評価するための指標
平均修復時間(MTTR：Mean Time to Repair)
システムが故障から復旧するまでの平均作業時間
障害発生後にどれだけ迅速に修復作業が完了するかを評価する指標
可用性
システムが特定の期間中に稼働可能な時間の割合を示す
可用性＝(稼働時間/総時間) × 100%
フェイルオーバー時間
システム障害発生時に、バックアップシステムに切り替わるまでの時間を示す
質問.icon 信頼性の向上のためのアーキテクチャ
単一障害点の排除
マルチAZ or マルチVPC
単一AZで単一VPCのシンプルな構成だと単一障害点により、システムダウンに弱くなる
そのため、ELBを利用したマルチAZまたは、マルチVPCにより単一障害点を排除するアーキテクチャ設計を行う
ヘルスチェックを行い片方が止まったら、トラフィックを稼働している方に流し、もう一方を障害復旧する
インスタンス障害
Elastic IPを設定して、同じパブリックIPを持つ別のインスタンスにIPをフローティングすることによる障害の対象方法もある
バックアップ
別リージョンや別AZにバックアップを取得保管することで耐障害性を高める
データ冗長性
バックアップ自動化
バックアップ暗号化とセキュリティ
スタンバイ構成
別リージョンや別AZにスタンバイ構成を取ることで即座にフェイルオーバーできるようにする データ同期
監視とアラート
復元手順の検証
事業継続性計画の作成
定期的な訓練とテスト
ドキュメントの維持管理
冗長性の設計
冗長ネットワーク
ロードバランシング
リソーススケーリング
自動スケーリング
キャパシティリザーブ
インシデント管理
インシデント対応プロセス
ポストモーテム分析